1. Technical Field
This disclosure relates generally to management of computing resources in a federated environment.
2. Background of the Related Art
Federated environments are well known in the art. A federation is a set of distinct entities, such as enterprises, organizations, institutions, or the like, that cooperate to provide a single-sign-on, ease-of-use experience to a user. A federated environment differs from a typical single-sign-on environment in that two enterprises need not have a direct, pre-established, relationship defining how and what information to transfer about a user. Within a federated environment, entities provide services that deal with authenticating users, accepting authentication assertions (e.g., authentication tokens) that are presented by other entities, and providing some form of translation of the identity of the vouched-for user into one that is understood within the local entity. Federation eases the administrative burden on service providers. A service provider (SP) can rely on its trust relationships with respect to the federation as a whole; the service provider does not need to manage authentication information, such as user password information, because it can rely on authentication that is accomplished by a user's authentication home domain, which is the domain at which the user authenticates.
In particular, a federated entity may act as a user's home domain that provides identity information and attribute information about federated users. An entity within a federated computing environment that provides identity information, identity or authentication assertions, or identity services, is termed an identity provider (IdP). Other entities or federation partners within the same federation may rely on an identity provider for primary management of a user's authentication credentials, e.g., accepting a single-sign-on token that is provided by the user's identity provider. An identity provider is a specific type of service that provides identity information as a service to other entities within a federated computing environment. With respect to most federated transactions, an issuing party for an authentication assertion would usually be an identity provider. Any other entity that provides a service within the federated computing environment can be categorized as a service provider. Once a user has authenticated to the identity provider, other entities or enterprises in the federation may be regarded as merely service providers for the duration of a given federated session or a given federated transaction.
Federated single sign-on (F-SSO) allows for user to interact directly with a service provider (SP) and leverage a secure trust relationship between the SP and an IdP for the purpose of receiving identity information in the context of authentication.
The typical model for identity provider discovery is a service that interacts directly with an end user. This approach is useful is a wide variety of scenarios, e.g., to allow the end user to choose from a list of available identity providers, or to facilitate attribute consent. Known discovery service implementations operate in a standalone manner, or by being embedded directly into a service provider. At a high level, one typical discovery model works as follows. The end user accesses an application (the SP) and then manually chooses an identity provider. The service provider then redirects the end user to the chosen identity provider. The end user authenticates to the identity provider, which (following authentication) then redirects the end user (typically through an HTTP-based redirect) back to the application. The IdP also provides the SP an identity assertion, such as a Security Assertion Markup Language (SAML) assertion, or a token, that provide evidence that the federated user has been authenticated. An end user session is then established between the federated user and the SP to complete the process.
Another typical discovery approach is for the SP to redirect the user to another service, which then interacts with the user to choose the IdP. That service then redirects the user to the IdP for authentication, and then the user is redirected back to the SP.
While the above-described workflows are appropriate for scenarios where a user has the ability to make a selection of different identity providers, in an intra-enterprise model there may be a just a single (logical) IdP service that has multiple IdP instances (points of presence) for scalability, availability or performance reasons. Thus, for example, a single identity provider may have identity provider instances in Tokyo, Bangalore, London or New York (each perhaps with a different hostname), with each instance theoretically being equally useful for carrying out the authentication function. The concept of identity provider discovery in this context is different from that described above (where the identity provider itself is selecting from among many such providers), because in the latter context a user does not know (and should not necessarily influence) the decision about which IdP instance is used.
It would be desirable to provide a technique to provide IdP instance-based discovery, and to automatically bind a user to a selected IdP instance.